1. Field of the Invention
This invention relates to intelligent devices such as computer systems, and more particularly to a system and method for batch-tuning multiple components of an intelligent device.
2. Description of the Related Art
Intelligent devices typically include one or more software components that are executable within the devices. Intelligent devices may include, but by no means are limited to: smart appliances, printers, personal digital assistants (PDAs), cellular/mobile phones, notebook computers, laptops, desktop computers, workstations, more powerful computer systems such as mainframes and high-end servers, even supercomputers.
Software components may include, but are not limited to, system software components including operating system software (e.g. Sun Solaris, Microsoft Windows, Windows NT, Linux, Macintosh, etc.), application software (e.g. database management, storage management, utility, etc.), and driver software for interfacing with and controlling hardware components. Hardware components may include, but are not limited to, processors, memory, firmware, storage devices, and external interfaces.
Software components often have parameters that are modifiable or “tunable” to change one or more aspects of the performance of the component. For example, a software application may have parameters that may be changed to adjust the amount of memory the application uses; using more memory may allow the application to run faster, while using less memory may allow the application to have a smaller “footprint.” Another example of component parameters is system software parameters, including operating system parameters, which may be used for tuning system software including operating system software. For example, a system software parameter may specify the network address of the intelligent device. Operating system parameters may be used to adjust virtual memory allocation. Yet another example of component parameters is driver parameters that may be used to control some aspect of a hardware component, such as the default speed of a modem. Typically, the driver sets a register of the hardware component with the parameter value.
The process of setting parameters of components in intelligent devices may be referred to as “tuning.” The term “tune” may include the notion of optimizing one or more components of a system for a particular environment, especially by adjusting numerical parameters designed as hooks for tuning, e.g. by changing “#define” lines in C. For example, an intelligent device may be tuned for time (fastest execution), tuned for space (least memory use), and/or tuned for configuration (most efficient use of hardware). The word “configure” may be used interchangeably with the word “tune.”
Components of an intelligent device may have a corresponding configuration tool with an interface that allows various parameters used to control the component to be modified or tuned. A configuration tool may be integrated in the component or may be a stand-alone application. Typically, the various parameter values associated with a component may be maintained in one or more files that may be referred to as “configuration files.” The configuration files may be stored within the intelligent device or alternatively may be stored externally to the intelligent device, e.g. on a server that is accessible by the intelligent device via a network. Any file format may be used for the configuration files so long as they are readable by the configuration tool. File formats may be public (e.g. plain text, Microsoft Word, Microsoft Excel, among others) or proprietary.
Typically, when an intelligent device is initially configured, each component's configuration file(s) will contain default values for the parameters used to tune the component. During the setup process of the intelligent device, a user may access the configuration tool for each of the components that the user desires to tune or reconfigure. The configuration tool may access the configuration file(s) for the component, and may display a portion or all of the parameters for the component. The user may then use the configuration tool to modify one or more of the parameters to “tune” the component as desired. The configuration tool may save the new parameter values to the configuration files if the user so desires. The user may repeat a similar process using the configuration tool of each of the components that the user desires to tune. The next time the component or components are initialized from the configuration file(s) (e.g. on reboot of the intelligent device), the new parameter values are read from the configuration file(s) by the component(s) and take effect to tune the component(s) as specified.
As an example, consider a system installed with Oracle, Veritas and Solaris components. Tunable parameters for this system exist in files with different types of markups, i.e./etc/system and $ORACLE_HOME/dbs/init.ora for Oracle and /etc/system for Solaris and Veritas. When first installed on a system, these applications are untuned and, as such, in most large-scale deployments, unusable. In a one-off installation, the system is tuned and then is ready for use. In large-scale implementations, there may be a plurality of systems requiring similar or identical tuned parameters.
FIG. 1 is a block diagram illustrating an exemplary intelligent device 100 and the prior art mechanism used to tune the device. Intelligent device 100 may include multiple components 102 (in this example, three components 102A, 102B and 102C are shown). These components may be hardware an/or software components as described above. At least some of the components may be tunable, and may have a corresponding configuration tool 104. The configuration tools 104 may be used to access one or more tunable configuration files 106 for the corresponding components 102. For example, component 102A is shown with corresponding configuration tool 104A, which may be used to access and modify configuration file 106A. To tune device 100, a user 150 may have to access two or more of configuration tools 104 to tune the individual configuration files 106 associated with the components 102 that the user wishes to tune. To apply the changes made in the configuration files 106, the components 102 may access the configuration files 106, for example, an application may read a configuration file 106 when restarted, or registers in a hardware component may be set to the new parameters in the configuration file when reinitialized. Some components 102 may have configuration tools 104 that may be used to apply the changed configuration file 106 to the component 102 directly (i.e. without restarting or re-initializing the component).
In the prior art, if one or more other intelligent devices need to be tuned to match a first device, to tune the one or more other devices, the user may have to repeat the accessing and entering of parameter values through each of the configuration tools 104 on each of the devices, or alternatively may transfer one or more of the configuration files 106 to the one or more other devices device. The second option may be difficult because the various configuration files 106 may be stored in diverse locations on the intelligent device 100, and may actually be in different locations on the one or more other devices. Also, one or more non-tunable parameters in the configuration files 106 may be different between the two devices, and overwriting the configuration files may unintentionally replace parameters that should not be changed. Another problem may arise if the second intelligent device does not include all of the components found in the first device, and therefore the user may have to determine the components that are and are not present.